v4 API: Forms and Landing Pages: Pagination and Total Count - #91

@noelherrick @mercedesb The PHP SDK has always had a distinction between Forms and Landing Pages (get_forms(), get_landing_pages()), with get_landing_pages() querying the forms endpoint and only returning results that are Landing Pages.

With the introduction of pagination support in the v4 API, get_landing_pages() becomes flaky, given that a per_page or cursor argument might not return any landing pages.

I'm unsure what the best route here is:

1. Drop pagination support on get_landing_pages. This would require querying the forms endpoint with per_page set to the maximum, and hope that an account hasn't had over 1,000 forms and landing pages in its lifetime.
2. Drop get_landing_pages as a supported method in the PHP SDK. Consumer / developers can filter results via get_forms if they only wanted to fetch landing pages. I like the convenience of having a get_landing_pages method though (we do something similar across all ConvertKit WordPress Plugins).
3. Investigate whether it's possible to add a filter to the API to return forms, landing pages or both. I'm unsure of the technical workload needed for this, or whether this is even viable. It would be fantastic if this could be an option; as a use case example, the WordPress Plugin would definitely benefit from it when we come to use the v4 API, as we distinguish between forms and landing pages in some settings there.

Would love to have your input!

With the introduction of pagination support in the v4 API, get_landing_pages() becomes flaky, given that a per_page or cursor argument might not return any landing pages.

@n7studios Thanks for calling this out. I have an open PR to be able to filter /v4/forms by either ?type=embed or ?type=hosted.

This should allow you to continue supporting get_landing_pages by using ?type=hosted

It should be merged and deployed within the next day or so.

With the introduction of pagination support in the v4 API, get_landing_pages() becomes flaky, given that a per_page or cursor argument might not return any landing pages.

@n7studios Thanks for calling this out. I have an open PR to be able to filter /v4/forms by either ?type=embed or ?type=hosted.

This should allow you to continue supporting get_landing_pages by using ?type=hosted

It should be merged and deployed within the next day or so.

That's awesome - thanks so much!

/v4/forms?type=hosted should work in prod now

/v4/forms?type=hosted should work in prod now

@mercedesb Thanks so much!

Would it be possible to add a boolean filter for archived? I've since realised pagination tests are still flaky as the default behaviour of the SDK and WordPress Plugins has always been to remove archived Forms and Landing Pages from the results returned, given we don't need to show them to the end user.

I'm happy with the default behaviour of archived forms being included in results - but any option to filter them out in the API request would be fantastic, so that the per_page and cursor pagination can be supported.

Sorry for not spotting this sooner.

Would it be possible to add a boolean filter for archived?

Whoops, we shouldn't have changed behavior. I'll add a status filter. We want to stay away from booleans :) But I'll update it so default behavior is active and then we can filter on the various statuses. The docs will have the full list. My plate is crazy full but I'll try to get to this later today but it might be tomorrow.

Ok, you can filter forms by status now. And it'll default to active. Docs have been updated with status options.

Ok, you can filter forms by status now. And it'll default to active. Docs have been updated with status options.

Awesome, thanks!

@noelherrick have requested a re-review as a few changes since the initial PR, so would be great to have you check this over.